![[レポート]Learn to deploy and self-manage blockchain nodes on AWS #BLC302-R1 #AWSreInvent](https://images.ctfassets.net/ct0aopd36mqt/3IQLlbdUkRvu7Q2LupRW2o/edff8982184ea7cc2d5efa2ddd2915f5/reinvent-2024-sessionreport-jp.jpg)
[レポート]Learn to deploy and self-manage blockchain nodes on AWS #BLC302-R1 #AWSreInvent
2024.12.03AWS 上にブロックチェーンノードを構築する方法について、Builders Session で学んできました！
セッション概要
タイトル
BLC302-R1 | Learn to deploy and self-manage blockchain nodes on AWS
説明
Join this builders’ session on empowering blockchain innovation to learn how to deploy blockchain nodes effectively using AWS technology. Led by AWS solutions architects, the session highlights the AWS Blockchain Node Runners initiative, an open source project that simplifies the complexities of blockchain deployment on AWS. Gain insights into the development processes, and explore deployment strategies. This session is ideal for both blockchain enthusiasts and professionals seeking to enhance their deployment capabilities on AWS with a variety of blockchain protocols, such as Ethereum, Solana, Polygon, and more. You must bring your laptop to participate.
スピーカー
Paulo Aragao, Principal Solutions Architect, AWS
Varsha Narmat, Web3/Blockchain Solutions Architect, Amazon Web Services
Guillaume Goutaudier, Sr. Enterprise Architect, AWS
Forrest Colyer, Sr. Web3 Specialist SA, Amazon Web Services (AWS)
Yinal Ozkan, Principal Solutions Architect, Amazon Web Services
セッション開始
参加者は 30 人ほどでしょうか？
SA の方ごとに机があり、一つを選んで座ります。
まず簡単な自己紹介からでしたが、Solution Architect for AWS!みたいな感じで乗り切れました(乗り切れていたのかは不明)。
今回は Blockchain Node Runners と呼ばれる、AWS 管理の OSS を扱います。
ブロックチェーンのノードを構築するにあたり、インスタンスサイズの選び方、sync を早くする方法、可用性などなど、考えることが多いので、それらを良い感じに動かす構成を AWS が用意してくれているということらしいです。
CDK ベースで構築されており、こんな形の設定ファイルを書くだけでインフラ含めて良い感じにしてくれます。
#############################################################
# Example configuration for Base nodes runner app on AWS #
#############################################################
## Set the AWS account is and region for your environment ##
AWS_ACCOUNT_ID="xxxxxxxx"
AWS_REGION="us-east-1"
## Common configuration parameters ##
BASE_NETWORK_ID="sepolia" # All options: "mainnet", "sepolia"
BASE_NODE_CONFIGURATION="full" # All options: "full", "archive"
BASE_INSTANCE_TYPE="m7g.2xlarge" # Reconneded for Insance Store: i3en.3xlarge, "x86_64"
BASE_CPU_TYPE="ARM_64" # All options: "x86_64", "ARM_64". IMPORTANT: Make sure the CPU type matches the instance type used
# Data volume configuration
BASE_DATA_VOL_TYPE="gp3" # Other options: "io1" | "io2" | "gp3" | "instance-store" . IMPORTANT: Use "instance-store" option only with instance types that support that feature, like popular for node im4gn, d3, i3en, and i4i instance families
BASE_DATA_VOL_SIZE="1000" # Current required data size in GB to keep both snapshot archive and unarchived version of it. For Sepolia 1000 will be sufficient.
BASE_DATA_VOL_IOPS="5000" # Max IOPS for EBS volumes (not applicable for "instance-store")
BASE_DATA_VOL_THROUGHPUT="700" # Max throughput for EBS gp3 volumes (not applicable for "io1" | "io2" | "instance-store")
BASE_L1_EXECUTION_ENDPOINT="https://ethereum-sepolia-rpc.publicnode.com" # Set your own URL to Ethereum L1 node: https://docs.base.org/tools/node-providers
BASE_L1_CONSENSUS_ENDPOINT="https://ethereum-sepolia-beacon-api.publicnode.com"
BASE_RESTORE_FROM_SNAPSHOT="true" # Download snapshot to speed up statup time
BASE_SNAPSHOT_URL="none" # Optionally provide the URL to download snpashot: https://docs.base.org/tutorials/run-a-base-node/#snapshots
# Example for Sepolia:
#BASE_L1_EXECUTION_ENDPOINT=https://ethereum-sepolia-rpc.publicnode.com
#BASE_L1_CONSENSUS_ENDPOINT=https://ethereum-sepolia-beacon-api.publicnode.com
# Example for Mainnet and with Ethereum Blueprint with Geth-Lighthouse client combination and private IP:
#BASE_L1_EXECUTION_ENDPOINT=http://172.31.15.220:8545
#BASE_L1_CONSENSUS_ENDPOINT=http://172.31.15.220:5052
## HA nodes configuration ##
BASE_HA_NUMBER_OF_NODES="2" # Total number of RPC nodes to be provisioned. Default: 2
BASE_HA_ALB_HEALTHCHECK_GRACE_PERIOD_MIN="500" # Time enough to initialize the instance
BASE_HA_NODES_HEARTBEAT_DELAY_MIN="120" # Time sufficient enough for a node do sync
朝に受けた cdk-eks-blueprints のセッションでも思いましたが、AWS が OSS として用意してくれている CDK ベースのパッケージは本当に便利だし、学びになるなぁとしみじみ思ってました。
ハンズオン
AWS の環境を払い出してもらったので、ハンズオンスタートです。
まず、ブートストラッピングを行います。
AWS_ACCOUNT_ID=$(aws sts get-caller-identity | jq -r .Account)
npx cdk bootstrap aws://$AWS_ACCOUNT_ID/$AWS_REGION
aws-blockchain-node-runners のリポジトリを clone します。
git clone https://github.com/aws-samples/aws-blockchain-node-runners.git
cd aws-blockchain-node-runners
npm install
ベースとして必要な IAM ロールだけ作成します。
npx cdk deploy base-common
設定ファイルを指定して、ブロックチェーンノードをデプロイします。
npx cdk deploy base-single-node --json --outputs-file single-node-deploy.json
CDK デプロイの間、CDK の素晴らしさみたいなことを語ってくれていました。
半分くらいしか聞き取れてないし、英語は喋れないけど、CDK 良いよねという気持ちは通じたのでめちゃくちゃ頷いておきました。
デプロイ完了後、下記のような構成が出来上がります。
作成した EC2 の中に乗り込んで、コンテナが正しくデプロイされていることを確認します。
$ sudo docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
node_execution latest dd3c76725e90 28 seconds ago 225MB
node_node latest dd3c76725e90 28 seconds ago 225MB
ちゃんと動いてそうです。
$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
edf7eff60369 node_node "bash ./op-node-entr…" 35 seconds ago Up 33 seconds 0.0.0.0:6060->6060/tcp, :::6060->6060/tcp, 0.0.0.0:7300->7300/tcp, :::7300->7300/tcp, 0.0.0.0:9222->9222/tcp, :::9222->9222/tcp, 0.0.0.0:9222->9222/udp, :::9222->9222/udp, 0.0.0.0:7545->8545/tcp, :::7545->8545/tcp node_node_1
362b307d89d0 node_execution "bash ./execution-en…" 36 seconds ago Up 35 seconds 0.0.0.0:8545-8546->8545-8546/tcp, :::8545-8546->8545-8546/tcp, 0.0.0.0:30303->30303/tcp, :::30303->30303/tcp, 0.0.0.0:30303->30303/udp, :::30303->30303/udp, 0.0.0.0:7301->6060/tcp, :::7301->6060/tcp node_execution_1
最新の同期ブロックのタイミングが、現在時刻とどれだけ離れているかを確認します。
$ echo Latest synced block behind by: $((($(date +%s)-$( \
> curl -d '{"id":0,"jsonrpc":"2.0","method":"optimism_syncStatus"}' \
> -H "Content-Type: application/json" http://localhost:7545 | \
> jq -r .result.unsafe_l2.timestamp))/60)) minutes
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 3090 0 3035 100 55 2762k 51258 --:--:-- --:--:-- --:--:-- 3017k
Latest synced block behind by: 623624 minutes
続いて VPC 内に CloudShell を起動して、JSON RPC 接続を行います。
$ curl -s -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' http://172.31.87.146:8545
{"jsonrpc":"2.0","id":1,"result":"0xa5d"}
同じ操作を BSC(BNB Smartchain) についても行い、下記構成を作成しました。
全く同じ操作感で異なる構成のブロックチェーンノードを構築できました！
VPC 内の CloudShell から RPC 接続を行って、動作確認を行い、問題無さそうです。
$ curl http://internal-bsc-ha-rpcno-0Hw3HNENOcbe-2115213425.us-east-1.elb.amazonaws.com:8545 -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}' | jq
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 530 100 471 100 59 78526 9836 --:--:-- --:--:-- --:--:-- 103k
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"currentBlock": "0x0",
"healedBytecodeBytes": "0x0",
"healedBytecodes": "0x0",
"healedTrienodeBytes": "0x0",
"healedTrienodes": "0x0",
"healingBytecode": "0x0",
"healingTrienodes": "0x0",
"highestBlock": "0x2a78e40",
"startingBlock": "0x0",
"syncedAccountBytes": "0x0",
"syncedAccounts": "0x0",
"syncedBytecodeBytes": "0x0",
"syncedBytecodes": "0x0",
"syncedStorage": "0x0",
"syncedStorageBytes": "0x0",
"txIndexFinishedBlocks": "0x0",
"txIndexRemainingBlocks": "0x1"
}
}
ブロックチェーンノードには様々な実装がありますが、それらの構築方法をある程度パターン化してくれるのはかなり嬉しいなと思いました。
まとめ
aws-blockchain-node-runners は聞いたこと無かったのですが、相当楽にブロックチェーンノードが立ち上がって良い感じでした。1 時間ということもあり、触りの部分をやっただけで終わってしまったので、日本に帰ったらもう少し触ってみようと思います。
